Single sign-on (SSO) is a specialized form of software authentication that enables a user to authenticate once and gain access to the resources of multiple software systems. In other words, SSO refers to a user's ability to log into a particular system, e.g., Windows 2000, and have that login information (i.e., username and password) be leveraged to all applications subsequently accessed during the login session, e.g., Microsoft Outlook.
Kerberos, which is a computer network authentication protocol originally developed by the Massachusetts Institute of Technology (MIT), and which is described in the Internet Engineering Task Force (IETF) Network Working Group Request for Comment: 1510, September 1993, the contents of which are incorporated herein by reference in their entirety, is a popular mechanism for applications to externalize authentication entirely. In general, under the Kerberos protocol, a user signs into a Kerberos server, which acts as a trusted third party, and is issued a ticket. The user's client applications can then present the ticket to various application servers that they wish to access.
More specifically, Kerberos, which uses a Key Distribution Center (KDC) consisting of an Authentication Server (AS) and a Ticket Granting Server (TGS), maintains a database including a shared secret key for each of the entities on a network (i.e., clients and servers). Each key in the database is known only to the network entity and Kerberos. When a client wishes to communicate with an application server, Kerberos will generate a session key that the entities can use to secure their interactions, encrypt the session key using the client's secret key, and transmit it to the client. The client can then use its secret key (i.e., its unique password) to decrypt the session key. Knowledge of the secret key, therefore, serves to prove the identity of the client.
Kerberos will also transmit a “ticket” to the client that contains the client's identity, the same session key, a timestamp, and other information, all encrypted using the application server's secret key. The client transmits this ticket to the application server it wishes to access, which decrypts the session key using its secret key. The server and client will then use the session key, which is now known to each of them, to communicate with one another. The combination of the ticket and the encrypted session key transmitted to the client by the Kerberos server is referred to as a “credential.”
In order to enable SSO authentication, the ticket gathering process involves two separate phases. In the first phase, the client requests a master ticket from the Kerberos Authentication Server (AS), and uses its password to complete the process. In particular, the client sends an authentication request to the AS, and in return receives a session key encrypted with the client's secret key/password along with a Ticket Granting Ticket (TGT). At this point the client will decrypt the session key using its password, and save the decrypted key and TGT. In the second phase, the client presents the master ticket (or TGT) to the Ticket Granting Server (TGS) and asks for a new ticket that can be used to access a particular application server. Specifically, the client sends a ticket request (or in essence a second authentication request) including the TGT and an identification of the application server to the TGS, and in response receives a Session, or Service, Ticket (ST). The ticket (i.e., the ST) that is returned to the client is encrypted; first with the secret key of the application server and then with the session key (received after the first ticket request and decrypted using the password). The client then uses the session key to decrypt one level of authentication, leaving the ticket encrypted only with the application server's secret key. The client can then send this ticket to the application server which can decrypt the ticket using its secret key to obtain the session key which will thereafter be utilized to support encrypted communications between the client and the server.
The first phase discussed above is only performed once—upon first logging into the system. The second phase is then repeated each time the user wishes to access a different application. Because the second ticket is encrypted with the session key, rather than the client's secret key/password, this enables the user to sign on using his or her password once, and then subsequently access various applications without having to re-sign on using a password—i.e., SSO authentication.
As illustrated, the typical Kerberos authentication system relies on a database that has a mapping of usernames to respective passwords, or secret keys. Kerberos, therefore, works only where the user has a static, or permanent, password. However, many organizations, for security reasons, now require the use of one-time passwords (OTPs) for any user authentication. An OTP is a password that repeatedly changes over time at various intervals. Using OTPs, rather than static passwords, increases the security of the communication since each password is only valid for a specified period of time. If an intruder becomes aware of a user's password at one point in time, therefore, the intruder would likely not be able to use that password at some later point in time.
As stated above, however, Kerberos would fail to work in conjunction with OTPs, since Kerberos relies on a permanent (or semi-permanent, since the user can change his or her password) password being mapped to the username in a database that is accessible by the AS. A need, therefore, exists for a means by which a user can use OTPs, yet still have the benefit of single sign-on authentication provided by Kerberos.